This invention relates to a new method for providing virtual storage resources to an operating system control program. With greater specificity, it relates to a method for providing virtual storage resources to an operating system control program through the creation of nondispatchable virtual machine control blocks that are usable only by the control program.
As is known, the virtual machine/system product (VM/SP) available from International Business Machines Corporation of Armonk, N.Y., includes an operating system used in a central computing complex such as the IBM System/370, which supports the execution of a variable number of tasks and allocates system resources among the tasks. This is also called multiprogramming. In this regard, a plurality of terminals or users can be connected to a central facility including a System/370. For each user, the VM/SP creates a virtual machine, which is a functional simulation of the central complex and all of its associated devices. The VM/SP controls the concurrent execution of multiple virtual machines on a single System/370.
As is known, the VM/SP includes a control program (CP) which manages the resources of the processing complex by means of the virtual machines in such a manner that each user appears to operate with sole and full control of the System/370 resources.
In a multiuser system, when a new user signs on, the control program VM/SP creates a virtual machine for that user. In creating the virtual machine, the CP creates apparent hardware resources consisting of software emulations of processing equipments such as a 370 CPU and virtual storage resources. In addition, a virtual machine control block (VMBLOK) is built which is resident in the CP. The VMBLOK is a data structure which provides the linkage between the CP and the virtual machine. The VMBLOK contains a number of status indicators and connectors; among these are linkages to the virtual storage allocated to the created virtual machine. These storage linkages include designation of the identity, location, and extent of the allocated virtual storage.
During the initialization of the CP, when the VM/SP is first compiled by the processing complex, a system virtual machine (SVM) is generated. The SVM is the CP's virtual machine, which the CP uses in implementing its control of system resources.
Conventionally, the computing complex controlled by the VM/SP includes a virtual storage facility compounded of real storage and direct access storage. The rear storage portion includes direct-access storage addressable by a program and from which instructions and other data can be transferred to processor hardware for subsequent execution or processing. The second portion consists of auxiliary storage, usually in the form of a direct access storage device (DASD) which is indirectly addressable. Typically, the auxiliary storage is indirectly addressed by a program in the CP that involves mapping or translation functions resident in a module of the CP for conversion of a logical address into an absolute memory address. Virtual storage generally is treated, for example, in Chapter 2 of Hwang and Briggs, "COMPUTER ARCHITECTURE AND PARALLEL PROCESSING," published in 1984 by McGraw-Hill.
As is known, the CP of the VM/SP includes a subsystem for allocating to a process a portion of the virtual storage resources of the computing complex. Typically, the virtual storage allocation is made when a virtual machine is created. Other CP subsystems manage the transfer of program information between real and auxiliary storage.
It will be appreciated by those skilled in the art that the allocation of real memory resources to a currently-executing process is done in the IBM VM/SP on a segmented page basis, with the allocation handled by a paging subsystem of the CP. For an understanding of the VM/SP paging subsystem, reference is made to IBM Publication LY20-0892-3, Release 4, entitled VIRTUAL MACHINE SYSTEM PRODUCT SYSTEM LOGIC AND PROBLEM DETERMINATION GUIDE.
The CP of the VM/SP has a basic, irreducible set of functions that enable it to operate a System/370 in a multiprogram context, serving a plurality of users as described above. Increasingly, system programmers are adding to this basic functional complement by integrating into the CP novel functions that enhance the primary mission of the CP. Other, specialized functions are also being added to the CP in many user-specific variations of the multiterminal version of the System/370. As the functional capacity of the CP grows, so, too, does its need for storage resources. However, the virtual storage resources available to the CP through the SVM are limited to 16 megabytes. Of this allocated capacity, 11 megabytes are typically needed to store the currently-unused CP portions in auxiliary storage. The CP, for its own current task, uses real storage, plus up to approximately 5 megabytes of virtual storage. Currently, the extra storage for added CP functions is found in these 5 extra megabytes of virtual storage.
Two procedures exist for obtaining unused portions of the storage capacity allocated to the CP. In the first, the SVM responds to CP process calls by inspecting the 5 megabyte virtual storage excess to determine whether any space is available. If space is available, the SVM will allocate it to the calling process. However, generally, substantially less than 5 megabytes is available, frequently resulting in the suspension of CP processes awaiting storage space until such space is available.
A second technique for obtaining storage capacity for CP processes is called extension. Extension is embodied in the well-known extended control-program support facility available for VM/SP versions of the System/370. This extended support facility obtains real storage capacity outside the portion allocated to the CP. However, its operation requires the suspension of all virtual machine activity while the real storage area is being obtained or released. In this regard, the extended support capability increases the overhead cost of the VM/SP and decreases its operational efficiency.